Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Considers GENERIC_CHART_AXES in viz migrations #23905

Conversation

michael-s-molina
Copy link
Member

SUMMARY

This PR changes the base migration class so that if GENERIC_CHART_AXES is enabled when migrating a chart, the temporal filter will be created for the new viz type. It also fixes an issue where renaming a key was not deleting the old key and ensures that the form_data backup is a deep copy of the original form_data.

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@codecov
Copy link

codecov bot commented May 2, 2023

Codecov Report

Merging #23905 (1f993e6) into master (3c381c5) will decrease coverage by 0.04%.
The diff coverage is 68.42%.

❗ Current head 1f993e6 differs from pull request most recent head 665ba6a. Consider uploading reports for the commit 665ba6a to get more accurate results

@@            Coverage Diff             @@
##           master   #23905      +/-   ##
==========================================
- Coverage   68.08%   68.04%   -0.04%     
==========================================
  Files        1939     1939              
  Lines       75007    75023      +16     
  Branches     8154     8154              
==========================================
- Hits        51066    51049      -17     
- Misses      21858    21891      +33     
  Partials     2083     2083              
Flag Coverage Δ
hive 52.99% <21.05%> (-0.02%) ⬇️
mysql 78.79% <68.42%> (?)
postgres 78.87% <68.42%> (-0.01%) ⬇️
presto ?
python 82.55% <68.42%> (-0.09%) ⬇️
sqlite 77.38% <68.42%> (-0.01%) ⬇️
unit 52.79% <0.00%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...set-frontend/src/components/Select/AsyncSelect.tsx 88.46% <ø> (ø)
superset-frontend/src/components/Select/Select.tsx 90.41% <ø> (ø)
superset/migrations/shared/migrate_viz/base.py 78.78% <68.42%> (-3.14%) ⬇️

... and 9 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Copy link
Member

@villebro villebro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few first pass comments

superset/migrations/shared/migrate_viz/base.py Outdated Show resolved Hide resolved
Comment on lines 93 to 94
if not granularity_sqla or not time_range:
return
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this correct - shouldn't we create at least a "No filter" time filter as long as granularity_sqla is defined? Or is time_range in practice always defined?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I changed it to use DEFAULT_TIME_FILTER when there's no time_range but there's a time column.

Copy link
Member

@villebro villebro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one last safeguard/comment

superset/migrations/shared/migrate_viz/base.py Outdated Show resolved Hide resolved
Co-authored-by: Ville Brofeldt <33317356+villebro@users.noreply.github.com>
@betodealmeida
Copy link
Member

Should migrations be affected by feature flags? What happens when a user runs a migration and later turns the feature flag?

@michael-s-molina
Copy link
Member Author

Should migrations be affected by feature flags? What happens when a user runs a migration and later turns the feature flag?

Not generically. In this case, we're talking about the GENERIC_CHART_AXES feature flag which is handled by the system automatically when you enable/disable it. Another important point is that this treatment is being added only to viz migrations.

@michael-s-molina michael-s-molina changed the title feat: Considers GENERIC_CHART_AXES in migrations feat: Considers GENERIC_CHART_AXES in viz migrations May 3, 2023
@michael-s-molina
Copy link
Member Author

@betodealmeida I changed the PR's title to make it clear that it's only affecting viz migrations.

@michael-s-molina michael-s-molina merged commit 10d640e into apache:master May 3, 2023
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 3.0.0 labels Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/M 🚢 3.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants